I found two correctness issues in the alias resolution path:

1. GROUP BY input-column precedence currently treats outer-scope columns as input columns. resolvesToInputColumn() calls scope.tryResolveField(...).isPresent(), but that can resolve through the query boundary into a correlated outer scope. As a result, a correlated subquery such as:

SELECT x,
       (SELECT COUNT(*) FROM table1 GROUP BY x)
FROM table_with_x

or an inner query with SELECT expr AS x ... GROUP BY x can have GROUP BY x blocked from resolving to the inner SELECT alias just because the outer query has a column named x. The stated rule is that GROUP BY prefers input columns, which should mean the current query source scope, not outer query columns. This should check the resolved field is local to the current source scope, e.g. via ResolvedField.isLocal() / relation id, before suppressing alias resolution.

2. ORDER BY aliases that point to window functions are re-analyzed as window functions in the ORDER BY phase. For example:

SELECT row_number() OVER (ORDER BY s1) AS rn
FROM table1
ORDER BY rn

ORDER BY rn is rewritten to the row_number() OVER (...) expression, so the function is collected both in analysis.getWindowFunctions(node) and analysis.getOrderByWindowFunctions(orderBy). QueryPlanner then plans SELECT window functions first and ORDER BY window functions again after switching to the ORDER BY scope, producing duplicate window planning instead of ordering by the SELECT output alias. For ORDER BY alias references, the planner should reuse the SELECT output symbol / field reference rather than treating the alias target as a fresh ORDER BY window expression.